The Lightweight Directory Access Protocol (“LDAP”) is a standard computer networking protocol for querying and modifying entries in a database. The basic protocol is defined in a group of Internet Engineering Task Force (“IETF”) Request for Comments (“RFC”) documents; various aspects of the current version of the protocol (version 3) are described in RFCs listed in the “LDAP Technical Specification Road Map” (RFC4510, published June 2006). The databases reachable through LDAP may contain any sort of data, but most commonly contain identity, contact and authorization information for people and organizations.
LDAP presents a hierarchical view of the data in a database. Records are presented as a tree of entries, each identified uniquely within the hierarchy by a Distinguished Name (“DN”). Entries contain one or more attributes, which consist of an attribute description (an attribute type with zero or more options), plus one or more values of the attribute. For example, an attribute type might be “givenName”, and its value might be a text string that is the given name of a person whom the record describes.
Access to data in an LDAP database is provided by an LDAP server, which responds to commands from an LDAP client. For example, a client may create a new entry, delete an entry, rename an entry, modify an entry, or (most commonly) retrieve the attributes in an entry. Attribute types and the meaning and encodings of their values are often specified in RFCs and other standards that are designed to support a particular application. For example, RFC2307 describes a set of attribute types and object classes that can be used to map between traditional Unix user and group authentication data and attributes in an LDAP database.
Unfortunately, there is a fair amount of semantic overlap between the attributes required by various application-supporting standards. In other words, two standards may both define a “password” attribute, but may use a different attribute type for the value, or may require a different encoding method. Thus, for example, one client may expect an LDAP user record to contain a password encoded as a Unix “crypt” string, while another client may expect the LDAP user record to contain the password encoded in a different form. Maintaining all the different attributes and values expected by LDAP clients imposes a significant administrative burden, and administrative errors may cause some applications to fill in ways that are difficult to debug.
Automated approaches to LDAP database management may be of value in this environment.